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Abstract 



We develop a logic for reasoning about object-oriented programs. The logic 
is for a language with an imperative semantics and aliasing, and accounts 
for self-reference in objects. It is much like a type system for objects with 
subtyping, but our specifications go further than types in detailing pre- and 
postconditions. We intend the logic as an analogue of Hoare logic for object- 
oriented programs. Our main technical result is a soundness theorem that 
relates the logic to a standard operational semantics. 
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1 Introduction 



In the realm of procedural programming, Floyd and Hoare denned two of 
the first logics of programs [Flo67, Hoa69]; many later formalisms and sys- 
tems built on their ideas, and addressed difficult questions of concurrency 
and data abstraction, for example. An analogous development has not taken 
place in object-oriented programming. Although there is much formal work 
on objects (see section 6), the literature on objects does not seem to con- 
tain an analogue for Floyd's logic or Hoare 's logic. In our opinion, this 
is an important gap in the understanding of object-oriented programming 
languages. 

Roughly imitating Hoare, we develop a logic for the specification and 
verification of object-oriented programs. We focus on elementary goals: we 
are interested in logical reasoning about pre- and postconditions of programs 
written in a basic object-oriented programming language (a variant of the 
calculi of Abadi and Cardelli [AC96]). Like Hoare, we deal with partial 
correctness, not with termination. 

The programming language presents many interesting and challenging 
features of common object-oriented languages. In particular, the opera- 
tional semantics of the language is imperative and allows aliasing. Objects 
have fields and methods, and the self variable permits self-reference. At the 
type level, the type of an object lists the types of its fields and the result 
types of its methods; a subtyping relation supports subsumption and inheri- 
tance. However, the language lacks many class-based constructs common in 
practice. It also lacks "advanced" features, like concurrency; some of these 
features have been studied in the literature (e.g., see [dB90, Jon92, YT87]). 

Much like Hoare logic, our logic includes one rule for reasoning about 
pre- and postconditions for each of the constructs of the programming lan- 
guage. In order to formulate these rules, we introduce object specifications. 
An object specification is a generalization of an object type: it lists the 
specifications of fields, the specifications of the methods' results, and also 
gives the pre/postcondition descriptions of the methods. 

Some of the main advantages of Hoare logic are its formal precision and 
its simplicity. These advantages make it possible to study Hoare logic, and 
for example to prove its soundness and completeness; they also make it 
easier to extend and to implement Hoare logic. We aim to develop a logic 
with some of those same advantages. Our rules are not quite as simple as 
Hoare's, in part because of aliasing, and in part because objects are more 
expressive than first-order procedures and give some facilities for higher- 
order programming (cf. [Cla79, Apt81]). However, our rules are precise; in 



1 



particular, we are able to state and to prove a soundness theorem. We do not 
know of any equivalent soundness theorem in the object-oriented literature. 

In the next section we describe the programming language. In section 3 
we develop a logic for this language, and in section 4 we give some examples 
of the use of this logic in verification. In section 5, we discuss soundness and 
completeness with respect to the operational semantics of section 2. Finally, 
in sections 6 and 7, we review some related work, discuss possible extensions 
of our own work, and conclude. 



2 The language 

In this section we define a small object-oriented language similar to the 
calculi of Abadi and Cardelli. Those calculi have few syntactic forms, but 
are quite expressive. They are object-based; they do not include primitives 
for classes and inheritance, which can be simulated using simpler constructs. 

We give the syntax of our language, its operational semantics, and a 
set of type rules. These aspects of the language are (intentionally) not 
particularly novel or exotic; we describe them only as background for the 
rest of the paper. 



2.1 Syntax and operational semantics 



We assume we are given a set V of program variables (written x, y, z, and w 
possibly with subscripts), a set T of field names (written f and g, possibly 
with subscripts), and a set M of method names (written m, possibly with 
subscripts). These sets are disjoint. 
The grammar of the language is: 



x 

false | true 

if x then else a± 

let x = a in b 



variables 
constants 
conditional 
let 



[fj = Xi jeL - n , uij = s(yj)bj i el - m ] object construction 
x.f field selection 

x.m method invocation 

x.i:=y field update 

Throughout, we assume that the names U and m.j are all distinct in the 
construct [fj = Xi tel - n } mj = s(yj)bj ■? el -- m ] ) and we allow the renaming of 
bound variables in all expressions. 

Informally, the semantics of the language is as follows: 
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• Variables are identifiers; they are not mutable: x := a is not a legal 
statement. This restriction is convenient but not fundamental. (We 
can simulate assignment by binding a variable to an object with a 
single field and updating that field.) 

• false and true evaluate to themselves. 

• if x then ao else a\ evaluates clq if x is true and evaluates a\ if x is false. 

• let x = a in b evaluates a and then evaluates b with x bound to the 
result of a. We define a ; b as a shorthand for let x = a in b where x 
does not occur free in b. 

• [fj = Xi * el - n ) mj = s(yj)bj J el " m ] creates and returns a new object 
with fields fj and methods nij. The initial value for the field fj is the 
value of Xi. The method uij is set to <;(yj)bj, where ? is a binder, 

is a variable (the self parameter of the method), and bj is a program 
(the body of the method) . 

• Fields can be both selected and updated. In the case of selection (x.f), 
the value of the field is returned; in the case of update (x.f := y), the 
value of the object is returned. 

• When a method of an object is invoked (x.m), its self variable is bound 
to the object itself and the body of the method is executed. The 
method does not have any explicit parameters besides the self variable; 
however, additional parameters can be passed via the fields of the 
object. 

Objects are references (rather than records), and the semantics allows alias- 
ing. For example, the program fragment 

let x = [f = zq] in let y = x in (x.f := z\ ; y.i) 

allocates some storage, creates two references to it (x and y), updates the 
storage through x, and then reads it through y, returning z\. 

In order to formalize the operational semantics, we use some notations for 
partial functions. We write A — 1 B for the set of partial functions from A to 
B. We write 0 for the totally undefined partial function. When / € A — 1 B, 
a G A, and b 6 B, we write f.(a i-> b) for the function that coincides with / 
except possibly at a, and that maps a to b. When <Zj 6 A iel - n are distinct 
and h £ B iel - n ) we write (a* i— > fej *e 1 -- n ) f or the function in A — 1 i? that 
maps Oj to 6j for i £ l..n and is otherwise undefined. 
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The formal operational semantics is in terms of stacks and stores. A 
stack maps variables to booleans or references. A store maps object fields 
to booleans or references and maps object methods to closures. We write 
cr, S h b v, a' to mean that, given the initial store o and the stack S, 
executing the program b leads to the result v and to the final store a'. 

We define the notions of store, stack, and result as follows: 

• We assume we are given a set of object names H. The set of results 1Z 
is H U {false, true}. 

• A stack is a function in V — 1 72. 

• A method closure is a triple of a variable x € V (standing for self), a 
program b, and a stack S; we write it (s(x)b,S). The set of method 
closures is C. 

• A store is a function cr in H — 1 ((J 7 U A4) — 1 (72 U C)). There is a 
condition on cr: if ft, € 7Y, f € J 7 , and a(h)(i) is defined, then a(/i)(f) €E 
72.; if /i 6 7i, m € A4, and <j(/i)(m) is defined, then a(/i)(m) 6 C. In 
other words, field names are mapped to results and method names to 
closures. 

The operational semantics is represented with a set of rules, given be- 
low. According to these rules, a variable x reduces to its value in the stack, 
without change in the store. The constants false and true reduce to them- 
selves, without change in the store. The execution of a conditional expres- 
sion consists in evaluating the guard and, depending on the outcome of this 
evaluation, evaluating one of the branches. The let construct evaluates an 
expression, binds a local variable to the result of that evaluation, and then 
evaluates another expression. The execution of an object construction re- 
quires evaluating the fields, constructing method closures, picking a new 
location, and mapping that location to an appropriate suite of fields and 
methods. The execution of a field selection on an object requires evaluating 
the object and then extracting the value of the appropriate field from the 
store. The execution of a method invocation is similar, but there the value 
returned is the result of evaluating the appropriate method body with an 
extended stack that maps the self variable to the value of the object. Finally, 
the execution of a field update modifies the store and returns the value of 
the object being affected. 
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Operational semantics 



Variables 

S(x) = v 
a, S h x v, a 

Constants 



a, S h false ~> /a/se, a cr, 5 h true ~> frwe, a 

Conditional 

<S(x) = false a, S h ai ~> d, a' 
ff,Sh if x £/jen ao efee ai ~» u, cr' 

S'(x) = true a, S h ao ~> v, cr' 
a,S h if x then ao e/se ai u, cr' 

Let 

cr, S 1 h a ~» v, a' cr', S.(x i— > t>) h 6 ^ t/, cr" 
a, S h let x = a in b v', a" 

Object construction 

Sfo) = vi iel - n h # dom(a) heU 

a ' = a .(h i— > (f- i— > ^ mj I— > (q{ yj )bj,S) J £l " m )) 

cr, 5 h ft = X< iel -«, mj = J ' el - m ] ~» ^ ^ 

Field selection 

5(a) = /t a £7^ <r(/t)(f) =v 
cr, S* h x.i ~» V, CJ 

Method invocation 

S(x) = ft h a{h){m) = {q{y)b, S') 

a, S' .(y i— > h) h 6 ~> v, cr' 

cr, 5* h X.m ~» f , cr' 

Field update 

S{x) = h heH cr(a)(f) is defined 

S(l/)=U (7 y = <7.(/ll-»(7(/l).(f •-»«)) 

a, 5 h x.i := y ~> /i, cr' 
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The judgment a, S h b ~> v, cr' represents only computations that termi- 
nate with a result, not computations that do not terminate or that termi- 
nate with an error. For example, intuitively, the execution of let x = [m = 
<r(y) true] in x.m terminates with the output true. Formally, we can derive 

a, S h let x = [m = q(y) true] in x.m ~» true, a' 

for all a and S and for some a'. On the other hand, intuitively, the execution 
of let x = true in x.m yields an error, while the execution of let x = [m = 
$(x) x.m] in x.m does not terminate. Formally, 

cr, S h let x = true in x.m ~> v, a' 

and 

a, S h let x = [m = s(x) x.m] in x.m ~> v, a' 

cannot be derived for any a, S, v, and a'. The search for a derivation of the 
former judgment "gets stuck" , while the search for a derivation of the latter 
judgment diverges. 

We have defined a small language in order to simplify the presentation 
of our rules. In examples, we sometimes extend the syntax with additional, 
standard constructs, such as integers. The rules for such constructs are 
straightforward. 

2.2 Types 

We present a first-order type system for our language. The types are Bool 
and object types, which have the form: 

[U-.Ai iel - n , m 3 :B 3 ^- m ] 

This is the type of objects with a field U of type Ai, for i € l..n, and with a 
method mj with result type Bj, for j 6 l..m. The order of the components 
does not matter. 

The type system includes a reflexive and transitive subtyping relation. 
A longer object type is a subtype of a shorter one, and in addition object 
types are covariant in the result types of methods. More precisely, the type 
[if.Ai <ei..n+p > mf.Bj i^- m +i] i s a subtype of [U:Ai iGl - n , mfB'- i el ~ m ] 
provided Bj is a subtype of Bp for j 6 \..m. Thus, object types are invariant 
in the types of fields; this invariance is essential for soundness [AC96]. 

Formally, we write h A to express that A is a well- formed type, and 
h A <: A' to express that A is a subtype of A'. We have the rules: 
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Well-formed types 



h Bool 

Subtypes 



|_ A . iel..n+p 

h [f^ iei..n+ P) mj -:Bj iei..m+9] < : [f. : ^. iei..n > mj :E^ J'ei..m] 

A typing environment is a (possibly empty) list of pairs x: A, where x is a 
variable and A is a type. The variables of each environment are distinct. We 
write 0 for the empty environment, and say that x is in E when it appears 
in some pair x: A in E. We write E h o to express that E is a well-formed 
typing environment. We have two rules for forming typing environments: 

Well-formed typing environments 

E h o h ^4 x not in E 
0 h o £,rih<> 

We write E h a : A to express that, in environment E, program a has 
type A. There is one typing rule for each construct, and an additional rule 
for subsumption. We write = for the relation of syntactic equality (up to 
reordering of object components). 

Well-typed programs 

Subsumption 

h A <: A' E h a : A 
E h a : A' 

Variables 

E,x:A, E' h o 
E~xTA^E t Vx~A 

Constants 

E h o E h o 

E h /ake : EooZ E h true : EooZ 

Conditional 

E h x : Bool Eh a 0 : A E\- a\ : A 
E h if x then oq else a\ : A 



|_ ^. i£l..n |_ £. j€l..m 

h [f i: ^ iel - n , rn~T^ J' el - m ] 



h EooZ <: EooZ 



h Ej <: BJ ? h Ej J'em+l..m+g 
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Let 



Eha:A E,x:A\~b:B 
E h let x = a in b : B 



Object construction for A ^ ft: A { iel - n , m f Bj jel ~ m ] 

Eho Eh xf. Ai iel - n E, yfAY- bj : Bj jel - m 
E\-[U = Xi iel - n , mj = q( yj )bj i el - m ] : A 

Field selection 

E\-x:[f:A] 
E h xi : A 

Method invocation 

E h x : [m: B] 
E h x.m : B 

Field update for A ^ ft: A { iel - n , my. Bj J' el - m ] 

^ h x : A k G l..n £ h !/ : 4 
£ h x.f fc := y : A 

This type system is much like those of common programming languages 
in that it is independent of verification rules. In particular, types are not 
automatically associated with specifications, and sub typing does not impose 
any "behavioral" constraints (as in the work of Liskov and Wing [LW94] , 
for example). However, as the next section explains, specifications are a 
generalization of types. 

3 Verification 

In this section, which is the core of the paper, we give rules for verifying 
object-oriented programs written in the language of section 2. We start with 
an informal explanation of our approach. 

3.1 Transition relations 

The purpose of our verification rules is to allow reasoning about pre- and 
postconditions. These pre- and postconditions concern the initial and final 
stores, the stack, and the result of the execution of a given program. 

In our rules, we express pre- and postconditions in formulas of standard, 
untyped first-order logic that we call transition relations. These formulas 
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mention the unary predicates alloc and alloc, two binary functions a and a, 
and the special variable r (which is not in the set V of program variables). 
Intuitively, d~(x, f ) is the value of field f of object x before the execution, and 
a(x,i) is its value after the execution. Similarly, alloc(x) and alloc(x) indi- 
cate whether x has been allocated before and after the execution. Finally, 
the variable r represents the result of the execution. 

For example, we may want to prove that, after any execution of the 
program x.i := y, the result is x and the field f of x equals y. We can 
express this with the transition relation r = x A &(x, f ) = y. As a second 
example, we may want to prove that, after any execution of x.f , the result 
equals the initial value of the field f of x, and that the store is not changed 
by the execution. This statement is captured by the transition relation 
r = a(x,f) A (Vy,z . a(y,z) = &{y,z) A (alloc(y) = alloc{y))). 

We work in standard first-order logic, so the functions a and a are total. 
Hence, b~(x,i) is defined even if alloc(x) does not hold, and &(x,i) is defined 
even if alloc(x) does not hold. In those cases, the values of a(x, f ) and &(x, f ) 
are not important. Similarly, the values of expressions such as <r(f,x) and 
alloc(i), which are intuitively meaningless, are not important. 

Given a program, a transition relation is much like a Hoare triple from 
the point of view of expressiveness. For example, a transition relation such 
as (a(x, f) = a(x, g)) => (&(x,f) = a(x,g)) can be understood as assuming 
a precondition (cr(x,f) = a(x,g)) and asserting a postcondition (a(x,f) = 
&(x,g)). However, the precondition and postcondition are given by separate 
formulas in a Hoare triple, while there is no such formal separation in a 
transition relation. This difference is largely a matter of convenience. 

Formally, we write that T is a transition relation to mean that T is a 
well-formed formula of the standard, untyped first-order logic, made up only 
of: 

• the constants false and true; 

• the variable r, the binary functions a and a, and the unary predicates 
alloc and alloc; 

• constants for field names (such as f); 

• other variables (such as x); 

• the usual logical connectives A, and V, and the equality predicate = 
(from which V, , =, 3, and 7^ can be defined as abbreviations). 
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The grammar for transition relations is thus: 

T ::= eo = ei | alloc(e) \ allocie) | ->T \ Tq A T± | ( Vx . T ) 
e ::= false \ true \ r \ x | f | cr(eo,ei) | <r(eo,ei) 

3.2 Specifications and subspecifications 

In order to permit reasoning about pre- and postconditions, our verification 
rules also deal with specifications, which generalize types. A specification 
can be either Bool or an object specification, of the form: 

[U:Ai m j :<;(v j )B j ::T j * 1 " m ] 

where each Ai and Bj is a specification, and each Tj is a transition relation. 
The variable yj is bound in Bj and Tj. Informally, an object satisfies the 
specification [f^: Ai ieL - ra ; mj -: q{yj)Bj ::Tj i Gl -- m ] if ; for i <E l..n, it has a field 
fi that satisfies specification Ai, and, for j G l..m, it has a method nij with 
a result that satisfies Bj and whose execution satisfies Tj when yj equals 
self. We may think of Bj as a predicate on the result, and then we may read 
Bj ::Tj as the conjunction of that predicate and Tj. As for object types, the 
order of the components of object specifications does not matter. 

Just like there is a subtyping relation on types, there is a sub specification 
relation on specifications. This relation is reflexive and transitive. A longer 
object specification is a subspecification of a shorter one, and in addition 
object specifications are covariant in the result specifications and in the 
transition relations for methods. Intuitively, when A and A' are object 
specifications, A is a subspecification of A' only if any object that satisfies 
A also satisfies A'. 

3.3 Rules for specifications 

In our rules for specifications, we use several judgments analogous to those 
introduced for types in section 2.2, and in those cases we use similar nota- 
tions but with a lh instead of a K In particular, we write lh A to express 
that A is a well- formed specification, and lh A <: A' to express that A is a 
subspecification of A'. The following rules for specifications generalize the 
corresponding rules for types: 

Well-formed specifications 

lh Ai iel - n lh Bj i el - m 

Tj is a transition relation J el - m 

lh Bool lh [f;: Ai iel -«, my. s{yj)Bj :: Tj ^ 1 - m ] 
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Subspecifications 

lh Bool <: Bool 



| h A . iel..n+p | h B . <; jel..m ||_ £. jem+l..m+q 

U-jol Tj => Tj J' el - m 

Tj is a transition relation J el -- m +i Tj is a transition relation -? el -- m 

lh [f^ * el "™+P, ^^yjjB^Tj 

<: [f i: ^ iel -«, m i :^)B;::^' eLm ] 

In this last rule, lhj 0 j represents provability in first-order logic with the stan- 
dard axioms for = and the axioms false ^ true and f 7^ g for every pair of 
different field names f and g. 

3.4 Specification environments 

A specification environment is much like a typing environment, except that 
it contains specifications instead of types. We write E lh o to mean that E 
is a well-formed specification environment. We have the rules: 

Well-formed specification environments 

E lh o E lh A x not in E 

0 lh o E,x:A\V o 

Here, given a well-formed specification environment E, we write E lh A to 
mean lh A and that all the free program variables of A are in E. We omit 
the obvious rule for this judgment. Similarly, when all the free program 
variables of a transition relation T are in E, we write: 

E lh T is a transition relation 

In order to formulate the verification rules, we introduce the judgment: 

E lh a : A :: T 

This judgment states that, in specification environment E, the execution of a 
satisfies the transition relation T, and its result satisfies the specification A. 

For this judgment, there is one rule per construct plus a subsumption 
rule; the rules are all given below. The rules guarantee that, whenever 
E lh a : A :: T is provable, all the free program variables of a, A, and T 
are in E. The rules have interesting similarities both with the rules of the 
operational semantics (section 2.1) and with the typing rules (section 2.2). 
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The treatment of transition relations reiterates parts of the operational se- 
mantics, while the treatment of specifications generalizes that of types. 

The subsumption rule enables us to weaken a specification and a tran- 
sition relation; it generalizes both the subsumption rule for typing and the 
standard rule of consequence from Hoare logic. The rule for if-then-else al- 
lows the replacement of the boolean guard with its value in reasoning about 
each of the alternatives. The rule for let achieves sequencing by represent- 
ing an intermediate state with the auxiliary binary function a and unary 
predicate alloc. (Note that the grammar for transition relations does not 
allow the auxiliary symbols a and alloc; however, \\~j 0 i applies to any first- 
order formula, even one that is not a transition relation.) The variable x 
bound by let cannot escape because of the hypotheses that E lh B and that 
E lh T" is a transition relation. The rule for object construction has a com- 
plicated transition relation, but this transition relation directly reflects the 
operational semantics; the introduction of an object specification requires 
the verification of the methods of the new object. The rule for method invo- 
cation takes advantage of an object specification for yielding a specification 
and a transition relation; in these, the formal self is replaced with the actual 
self. The remaining rules are mostly straightforward. 

In several rules, we use transition relations of the form Res(e), where e 
is a term; Res(e) is defined by: 

Res(e) = r = e A (V x,y . a(x,y) = a(x,y) A (alloc(x) = al'loc(x)) ) 

and it means that the result is e and that the store does not change. We 
also write ui [142/^3] for the result of substituting 112 for U3 in u\. 

Well-specified programs 

Subsumption 

lh A <: A 1 \V fol T T' E lh a : A T 
E lh A' E lh T' is a transition relation 
E lh a : A' :: V 

Variables 

E,x:A,E' lh o 
E,x:A,E' \\-x:A:: Res(x) 

Constants 

£lho £lho 
E lh false : Bool :: Res (false) E lh true : Bool :: Res(true) 
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Conditional 



E Ih x : Bool :: Res(x) 

E Ih a 0 : A 0 :: T 0 A 0 [frt/e/x] = A[irae/x] T 0 [trae/x] = T[irae/x] 
£ Ih ai : A x :: T\ Ai[/afae/x] = A[false/x] Ttfalse/x] = T[false/x] 
E Ih if x then ao else a\ : A :: T 

Let 

£lha:,4::T E,x: Ah b : B T' 
E \\- B E Ih T" is a transition relation 
hj 0 | T[<t/(T, alloc/ alloc, x/r] A T'[a/a, alloc/ alloc] => T" 
Eti- let x = a in b: B :: T" 

Object construction for A = ft: A; iel - n , nx,: cfojO-Bj :: T j J6l " m ] 

£ Ih o E Ih Xi : Ai :: Res( Xi ) iel - n E, Vj : A Ih bj : 5j :: Tj ^ e1 -" 
£ Ih ft = Xi iel - n , mj = ^{yj)bj jel - m ] : A :: 
-^alloc{r) A alloc(r) A 
( y z . z ^ r =4> (alloc(z) = alloc(z)) ) A 
<r(r, fi) = xi A ■ ■ ■ A &(r, f„) = x n A 
(\/ z,w . z ^ r =>■ u;) = u>) ) 

Field selection 

£ Ih x : [f: A] :: i?es(x) 
£lh x.f: A:: i?es(<r(x, f)) 

Method invocation 

£ Ih x : [m:?(y)S::T] :: i?es(x) 
£ Ih x.m : B[x/y] :: T[x/y] 

Field update for A = ft: Ai iel - n , my. ^{z j )B j :: Tj jel - m ] 

E\\- x : A:: Res(x) k G l..n £ Ih y : A fc :: -Res(y) 
£ Ih x.f fe := y : A :: 

r = x A cj(x,ffc) = y A 

(Vz,w. -i(z = xAw = ffe) <r(z, w;) = w) ) A 
(Vz. alloc(z) = alloc(z) ) 
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4 Examples 



We discuss a few instructive examples, some of them with derivations. From 
now on, we use some abbreviations, allowing general expressions to appear 
where the grammar requires a variable. In case o, ai ieL - n ) and b are not 
variables, we define: 

if b then ao else a\ = let x = b in if x then ao else a\ 

[fj = cii iel - n j uij = s(yj)bj i el -- m ] = let x\ = a\ in ■ ■ ■ let x n = a n in 

[U = Xl m 3 = ,( yj ) bj ^- m ] 

al = let x = a in x.i 

a.m. = let x = a in x.m 

a.f := b = let x = a in 

(x.f ; let y = b in x.i := y) 

where the variables x and X{ * el -- n are fresh. Rules for these abbreviations 
can be derived directly from the rules for the language proper. For example, 
for field selection, we may use the rule: 

Eh a: [f: A] :: T 
E Ih a.f : A :: ( 3 x . T[x/r] A Res(a(x, f )) ) 

4.1 Field update and selection 

Our first example concerns the program: 

([£ = false]. £ := true)! 

This program constructs an object with one field, f, whose initial value is 
false. It then updates the value of the field to true. Finally, a field selection 
retrieves the new value of the field. 

Using our rules, we can prove that r = true holds upon termination of 
this program. Formally, we can derive the judgment: 

0 |h ([£ = false]! := true)!: Bool :: (r = true) 

4.2 Aliasing 

The following three programs exhibit the role of aliasing: 

let x = [£ = false] in let y = [g = false] in (y.g := true ; x.f) 
let x = [£ = false] in let y = [£ = false] in (y! := true ; x!) 
let x = [£ = true] in let y = x in (y! := false ; x.f) 
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For each of these programs we can verify that r = false. The first program 
shows that an update of a field g has no effect on another field f . The second 
program shows that separately constructed objects have different fields, even 
if those fields have the same name. The third program shows that an update 
of a field of an aliased object can be seen through all the aliases. 

4.3 Method invocations and recursion 

The next example illustrates the use of method invocation; it shows how 
object specifications play the role of loop invariants for recursive method 
invocations. 

We consider an object-oriented implementation of Euclid's algorithm for 
computing greatest common divisors. This implementation uses an object 
with two fields, f and g, and a method m: 

[f=l, g=l, 
m = if V-i < y-S then (y.g := y.g - y.f ; y.m) 

else if y.g < y.f then (y.f := y.f - y.g ; y.m) 
else y.f ] 

Setting f and g to two positive integer values and then invoking the method 
m has the effect of reducing both f and g to the greatest common divisor of 
those two values. 

We can prove that this object satisfies the following specification: 

[ f: Nat, g: Nat, 
m: s(y) Nat :: 1 < cr(y, f) A 1 < a{y, g) => 

r = o-(y,f) A r = a(y,g) A r = gcd(a(y,f),a(y,g)) } 

(The proof relies on the addition of standard axioms about integers to the 
underlying first-order logic.) In verifying the body of the method m, we can 
use the specification of m, recursively. The derivation included in the next 
example demonstrates how a method specification can be used recursively 
in a formal proof. 

4.4 Nontermination 

As we mentioned initially, our rules are for partial correctness, not for ter- 
mination. Nontermination can easily arise because of recursive method in- 
vocations. Consider, for example, the nonterminating program: 

[m = ?(#) x.m].m 
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Using our rules, we can prove that anything holds upon termination of this 
program, vacuously. Formally, we can derive the judgment: 

0 Ih [m = q(x) x.m].m : A :: T 

for any specification A and transition relation T without free variables. 

We show the proof as a sequence of judgments, from the desired conclu- 
sion back to "true", indicating between braces the rules applied and other 
justifications. We write False and True as abbreviations for the formulas 
(false = true) and (false = false), respectively. 

0 Ih [m = q(x) x.mj.m : A :: T 
<= { subsumption, using the assumptions and \\-f 0 i False =4> T } 

0 Ih [m = q(x) x.m].m : A :: False 
= { shorthand } 

0 Ih let x = [m = q(x) x.m] in x.m : A :: False 
<= { let } 

0 Ih [m = q(x) x.m] : [m: q(x)A :: False] :: True 

0, x: [m: q(x)A:: False] Ih x.m : A :: False 

0 Ih A 

E Ih False is a transition relation 

hj 0 | True A Fa/se =>• Fa/se 
<= { assumptions and first-order logic } 

0 Ih [m = q(x) x.m] : [m: s(x)A :: False] :: True 

0, x: [m: q(x)A:: False] Ih x.m : A :: Fa/se 
■<= { subsumption; object construction } 

0 Iho 

0, x: [m: q{x)A:: False] Ih x.m : A :: False 

0, x: [m: <r(x)^4 :: False] Ih x.m : A :: Fa/se 
<= { well-formed specification environments; simplification } 

0, x: [m: q(x)A:: False] Ih x.m : A :: False 
<= { method invocation } 

0,x: [m: q(x)A :: False] Ih x : [m: q(x)A :: False] :: Res(x) 
<= { variables } 

0, x: [m: q(x)A:: False] Ih o 
<= { well-formed specification environments } 

0 Iho 

Ih A 

False is a transition relation 
<= { well-formed specification environments; assumptions } 

true 
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Note that in the step that uses the rule for object construction we derive 
0 lh [m = q(x) x.m] : [m: s(x)A :: False] :: True from 0, x: [m: q(x)A :: False] Ih 
x.m : j4 :: False. The assumption x: [m: q{x)A :: Fa/se] then enables us to 
check that the method body x.m implements the specification for m given 
in [m: q(x)A:: False]. Thus, recursively, we use the specification of an object 
in verifying its implementation. 

4.5 Putting it all together 

Let oo be the following object: 

[ f = false, m = q{s) if s.f then false else true ] 

Below we give a detailed proof that this object satisfies the following speci- 
fication: 

[ f: Bool, 

m: Bool :: (<r(s, f) = false =4> r = true) A 
(<r(s, f) = true =4> r = /afee) ] 

The specification says that the object's m method returns the negation of 
the object's f field. Below we also give a detailed proof of the following 
judgment, illustrating the use of ao: 

0 lh let x = oo in (x.f := true ; x.m) : Bool :: r = false 

The proofs include applications of all our verification rules. 

For convenience in the proofs, we define a transition relation T, as fol- 
lows: 

T = (cr(s, f) = false =4> r = true) A (<r(s,f) = true =4> r = false) 

We also define to be the specification of ao: 

A 0 = [ i:Bool, m:q(s)Bool::T] 

We begin with a proof of the specification of ao, more precisely, with a 
proof of the judgment E lh ao : A> :: r = r. We omit some easy steps, and 
use our standard abbreviations. For any well-formed environment E not 
containing s, we calculate: 

E lh ao : Aq :: r = r 
<= { subsumption } 
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E Ih a 0 : :: 

-ialloc(r) A alloc(r) A (Vz. z^r =^ (alloc(z) = alloc(z)) ) A 
<j(r, f ) = /a/se A(Vz,ti;.Z7^r=^ <t(z, w;) = &(z, w) ) 
-4= { object construction } 

E Ih o 

E h /a/se : Bool :: Res (false) 

E, s: Aq Ih i/ s.f then false else true : 5oo/ :: T 
■<= { is well-formed; constants } 

E, s: Aq Ih if s.f then false else true : -Boo/ :: T 
<^= { conditional } 

E,s:A 0 Ih si: Bool :: fles(cr(s,f)) 

i?, s: Aq Ih /a/se : SooZ :: 

(true = false =4> r = true) A (true = true =4> r = false) 

E, s: Aq Ih true : -Boo/ :: 

(false = false =4> r = true) A (false = true =4> r = false) 
<= { field selection; subsumption, using -i(/a/se = trwe) } 

s:Ao Ih s : A 0 :: Res(s) 

E, s: Aq Ih false : Bool :: Res(false) 

E, s: Aq Ih true : -Boo/ :: Res(true) 
<= { variables; constants } 

E,s:A 0 Ih o 

■<= { well-formed specification environments } 

E Ih o 

Eh Aq 

s not in E 

<= { E is well-formed and does not contain s; misc. rules } 

true 

Next, we prove that the program let x = oq in (x.f := true ; x.m), which 
contains ao, yields the result false: 

0 Ih let x = ao in (x.f := true ; x.m) : Bool :: r = /a/se 
4= { let } 

il) \\- a 0 : Aq :: r = r 

0, x: Aq Ih x.f := irwe ; x.m : Bool :: r = false 
0 Ih Bool 

0 Ih (r = false) is a transition relation 

\\-f 0 l x = x A r = /a/se =4> r = /a/se 
<= { previous proof about ao; misc. rules } 

0, x: Aq Ih x.f := true ; x.m : Bool :: r = false 
<= { definition of ; } 
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0, x: Aq lh /ei z = x.f := irwe in x.m : 5ooZ :: r = false 
4= { let } 

0, x: ylo II" £-f := true : ^4o :: f) = 

0, x: A), -z: ^0 II" x.m : 5ooZ :: <r(x, f) = true =4> r = /afee 

0,x: A 0 lh Bool 

0, x: ylo lh (r = false) is a transition relation 

\\-f 0 l (i(x,f) = true A (cr(x,f) = true =4> r = false) =4> r = /aZse 
<^= { misc. rules } 

0, x: A) lh x.f := irwe : Aq :: cr(x, f ) = true 

0, x: z: Aq lh x.m : Bool :: <r(x, f) = true =4> r = /afee 
<= { subsumption; field update; method invocation } 

0,x: Aq lh x : A 0 :: Res(x) 

0, x: Ao, z: Aq lh x : :: Res(x) 
<= { variables; misc. rules } 

true 

5 Soundness and related properties 

In this section we discuss the relation between verification and typing, ob- 
taining two simple results. We then discuss the relation between verification 
and operational semantics, proving in particular a soundness theorem. The 
soundness theorem is the main technical result of this paper. Finally, we 
comment on completeness. 

5.1 Typing versus verification 

Our first result establishes a correspondence between typing rules and veri- 
fication rules: it says that only well-typed programs can be verified. 

Proposition 1 // E lh a : A :: T then E' h a : A' for some E' and A' 
(obtained from E and A by deleting transition relations). 

This result provides a first formal sanity check for the verification rules. 
It also highlights a limitation of the verification rules: for example, it im- 
plies that the verification rules do not enable us to derive that the program 
if true then true else {true!) yields r = true, because this program is not 
well- typed. We do not view this limitation as a serious one because we are 
primarily interested in well-typed programs. 

Conversely, every well-typed program can be verified, at least in a trivial 
sense: 
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Proposition 2 // E' h a : A' then E lh a : A :: (r = r) /or some and A 
(obtained from E' and A' by inserting trivial transition relations). 

5.2 Soundness 

We have both an axiomatic semantics (the verification rules) and an opera- 
tional semantics. As we prove next, the two semantics agree in the sense that 
all that can be derived with the verification rules is true operationally. For 
example, if a program yields a result according to the operational semantics, 
and the axiomatic semantics says that the result is true, then indeed the 
result is true. We call this property soundness. 
A special case of our soundness theorem is: 

Theorem 1 Assume that the operational semantics says that program b 
yields result v when run with an empty stack and an empty initial store (that 
is, 0, 0 h b ~> v, a 1 is provable with the rules of section 2.1 for some a'). If 
0 lh b : Bool :: (r = true) is provable then v is the boolean true. Similarly, if 
0 lh b : Bool :: (r = false) is provable then v is the boolean false. 

The statement of this theorem clearly expresses the consistency of the veri- 
fication rules with the operational semantics. It is however unsatisfactory in 
at least two respects: (i) it does not apply to programs with free variables, 
to programs that return objects, or to programs that start running with a 
nonempty store; (ii) it cannot be proved directly anyway. 

Going a little beyond the first special case, we can show that if b yields 
result v when run with an empty stack and an empty initial store, and if 
0 lh b : A :: T is provable, then v "satisfies" A, and T holds when interpreted 
as a predicate on the initial and the final stores, with v as the value of r. 

The full statement of our soundness theorem is as follows. 

Theorem 2 Assume that a, S h a ~» v, a' is provable and that \= a. If 
E lh a : A :: T is provable and S |= S : E, then (S,a,a',v) \= T and there 
exists £' such that S' y S, £' |= a', and S' |= v : {A, S). 

The notations used in this statement are defined precisely in the appendix, 
where we also prove the theorem. Here we explain these notations only 
informally. The hypothesis T, \= a means that the store a meets the store 
specification S. The hypothesis S h^ S : E means that the variables in the 
stack S meet the specifications given in E in the context of S. The store 
specification S is needed because the initial store a may be nonempty; sim- 
ilarly, the use of E as a specification for the stack S is needed because the 
program b may have free variables. The conclusion (S, a, a' , v) \= T means 
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that the transition relation holds when we interpret its symbols using S, a, 
a', and v (for example, taking v as the value of r). The conclusions £' y S 
and £' |= cr' imply that £' agrees with S but possibly specifies additional 
objects in the store (those allocated in going from a to a'); these two con- 
clusions appear in order to permit a direct inductive proof. Finally, the 
conclusion S' |= v : (A, S) means that the output v meets the specification 
A in the context of Tl and S. 

Theorem 1 is a corollary of Theorem 2. As another corollary, we obtain 
a soundness theorem for the type system of section 2.2. Therefore, as might 
be expected, our soundness proof is no less intricate than proofs of type 
soundness for imperative languages. In fact, Theorem 2 generalizes concepts 
recently developed for sophisticated proofs of type soundness [AC96, Har94, 
Ler92, Tof90, WF94]. New techniques are required because specifications, 
unlike ordinary (non-dependent) types, may contain occurrences of program 
variables. 

5.3 Completeness issues 

While we have soundness, we do not have its converse, completeness. Unfor- 
tunately, our rules do not seem to be complete even for well- typed programs. 

Careful examination of the following three similar programs reveals a 
first difficulty: 

bi = let x = (let y = true in [m = q(z) y]) in x.m 
t>2 = let y = true in (let x = [m = <;(z) y] in x.m) 
63 = let x = (let y = true in [f = y, m = $(z) z.f]) in x.m 

All three programs are well- typed and yield the result true. Using our rules, 
we can prove 0 lh 62 : Bool :: (r = true) and 0 Ih 63 : Bool :: (r = true) 
but not 0 lh 61 : Bool :: (r = true). A reasonable diagnosis is that the 
judgment E lh a : A :: T does not allow sufficient interaction between A and 
T (particularly in the rule for let). One remedy is transforming b\ into 62 
(by let-floating [PPS96]) or into 63 (by adding an auxiliary field). We have 
considered other remedies, but do not yet know which is the "right" one. 

A deeper difficulty arises because the verification rules rely on a "global 
store" model. As Meyer and Sieber have explained [MS88], the use of this 
model is a source of incompleteness for procedural languages with local 
variables. Some of their remarks apply to our language as well. For ex- 
ample, the following program is reminiscent of their Example 2: let x = 
[f = true] in (y.m ; x.i). This program will always return true because 
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the method invocation y.m cannot affect the field f of the newly allocated 
object x. We can prove this, but only by adopting a strong specification 
for y, for example requiring that y.m not modify the field f of any object. 
Recently, there has been progress in the semantics of procedural languages 
with local variables (e.g., see [OT95, PS93]). Some of the insights gained in 
that area should be applicable to reasoning about objects. 

6 Past and future work 

As we mentioned in the introduction, there has been much research on spec- 
ification and verification for object-oriented languages. The words "object" 
and "logic" are frequently used together in the literature, but with many 
different meanings (e.g., [SSC95]). We do not know of any previous Hoare 
logic for a language like ours. 

Our work is most similar to that of Leavens [Lea89], who developed a 
Hoare logic for a small language with objects. The language is statically 
typed and includes a subtyping relation, but does not permit side-effects 
or aliasing. In another related study, de Boer [dB90] gave verification rules 
for the parallel language POOL. These rules apply to programs with side- 
effects and aliasing, but without subtyping or recursive methods, and with 
only one global implementation for each method (rather than one imple- 
mentation per object). Both Leavens and de Boer obtained soundness re- 
sults. Recently, in his dissertation [PH97], Poetzsch-Heffter considered how 
to integrate Larch-style interface specifications with Hoare-style verifica- 
tion techniques for object-oriented programs. Further, Poetzsch-Heffter and 
Miiller [PHM98] provided a proof system for a class-based language, repre- 
senting properties of the type system of the language in axioms. 

Much of the emphasis of the previous research has been on issues of 
refinement and inheritance. Lano and Haughton [LH92], Leavens [Lea89, 
Lea91], and Liskov and Wing [LW94] all studied notions of subtyping and of 
refinement of specifications (similar to our subspecification relation, though 
in some respects more sophisticated). Stata and Guttag [SG95] studied the 
notion of subclassing, and presented a pre-formal approach for reasoning 
about inheritance. Lano and Haughton [LH94] have collected other research 
on object-oriented specification. 

In some existing formalisms (e.g., Leavens's), specifications can be writ- 
ten in terms of abstract variables. Specifications at different levels of ab- 
straction can be related by simulation relations or abstraction functions. 
Undoubtedly the use of abstraction is important for specification and veri- 
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fication, and probably an essential ingredient of any practical programming 
tool. We leave a full treatment of abstraction for future work; some re- 
sults on abstraction appear in Leino's dissertation [Lei95], which also gives 
a guarded-command semantics for objects and uses this semantics for rea- 
soning about programs. 

Several other extensions to our logic might be interesting. For example, 
it would be trivial to account for a construct that compares the addresses 
of two objects, or for a cloning construct. Recursive types and recursive 
specifications would be helpful in dealing with programs that manipulate 
unbounded object data structures, which our logic treats only in a limited 
way; a recent continuation of this work considers recursion [Lei98] . Rules for 
subclasses and inheritance would be important for treating standard class- 
based languages like Modula-3 and Java; perhaps one could develop a formal 
version of Stata and Guttag's approach. It remains to be seen whether class- 
based constructs should be included explicitly or whether their simulation in 
terms of simpler object-based constructs provides a sufficiently convenient 
basis for reasoning. The addition of concurrency primitives would be more 
difficult; it would call for a change of formalism, similar to the move from 
Hoare logic to Owicki-Gries logic [OG76] . 

7 Conclusions 

In summary, the main outcome of our work is a logic that enables us (at 
least in principle) to specify and to verify object-oriented programs. To 
our knowledge, our notations and rules are novel. They permit proofs that, 
despite their simplicity, are outside the scope of previous methods. However, 
our work is only a first step; we hope that it stimulates further research. 

Secondarily, we hope that our logic will serve as another datapoint on 
the relations between types and specifications. In the realm of functional 
programming, specifications can be seen as a neat generalization of ordi- 
nary types (through notions such as dependent types, or in the context of 
abstract interpretations). In our experience with imperative object-oriented 
languages, the step from types to specifications is not straightforward; still, 
type theory is sometimes helpful, for example in suggesting techniques for 
soundness proofs. 
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Appendix: Soundness (definitions and theorems) 



The soundness theorem requires several auxiliary notions. Before giving 
their definitions, we motivate each of them informally. 

As part of the soundness theorem, we show that if the verification rules 
say that a satisfies the specification A and if, operationally, a yields the 
result v, then v satisfies A. Making precise the assertion that v satisfies A 
is delicate for several reasons. 

One problem is that program variables may occur free in A. We sur- 
mount this difficulty by considering specification closures. A specification 
closure is a specification paired with a stack that gives values for the free 
program variables of the specification. (See Definition 1.) Instead of saying 
that v satisfies A, we can say that v satisfies the specification closure (A, S), 
where S is the stack used for the execution of a. 

Definition 1 (Specification closures) 

• A specification closure is a pair (A, S) where A is a specification and 
S is a stack such that the free program variables of A are all in the 
domain of S. 

• Given a specification A and a stack S, we write AS for the result of 
replacing the free program variables of A by the corresponding results 
from S. Similarly, we write TS when T is a formula. 

• We handle AS and TS as formal expressions by treating all object 
names as free variables. In particular, we may write the subtyping 
assertion A'S' <: AS; this assertion is defined by the standard rules 
for subtyping. (We omit a lb in A'S' <: AS in order to stress that this 
is not a judgment of our verification system.) 

A second problem is that v may be an address in the store (that is, 
an object name) and the store may contain cycles; cycles impede inductive 
definitions. We surmount this difficulty by introducing store specifications, 
which associate specification closures with object names. 

Definition 2 (Store specifications) 

• A store specification is a partial function that maps object names (from 
the set H) to specification closures. 

• Given store specifications £ and X/, we write £' >z £ ifT,' extends S. 
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• Given a store specification S, a specification closure (A,S), and a 
result v, T, \=q v : (A, S) holds if either A is Bool and v is one of false 
and true, or if (A, S) is E(t> ) and v G TL. 

• S |= v : (B,S) holds if there exist B' and S' such that B'S' <: BS 
and S \= 0 v : (B',S r ). 

The verification of a takes place with a particular specification envi- 
ronment, and the execution of a takes place with a particular stack. The 
soundness theorem assumes that the stack matches the environment, in the 
sense that if Vi is the value for Xi in the stack, and A{ is its specification in 
the environment, then Vi satisfies a suitable specification closure (A4, Si). 

Definition 3 (Stacks vs. environments) The relation S |= S : E is de- 
fined inductively by: 

• If T, is a store specification, then S |= 0 : 0. 

• 7/S |= S : E, S |= v : (A, S), and x is not in E, then £ |= S.(x 1— > v) : 
(E,a;:A). 

For a store specification to be useful, it needs to be consistent with the 
particular store under consideration. We define this consistency relation 
without breaking cycles in the store, as follows. 

Definition 4 (Stores vs. store specifications) Given a store a and a 
store specification S, S |= a holds if S and cr /iaue the same domain, 
and for every v in their domain, S(u ) /ias t/ie /orm (A, £) where A is 
[UAi jel -«, mj:q{ V j)Bj::Tj ^ l - m ], and 

• for i 6 l..n, cr(f)(fj) is defined and S |= cr(f)(fj) : (A^S 1 ); 

• /or j G l..m, cr(v)(mj) is of the form (s{yj)bj, S) , and E,yj:A lh 6j : 

:: Tj /or some £7 suc/i t/iat S (= 5 : 

As part of the soundness theorem, we show also that if the verification 
rules say that a satisfies the transition relation T and if the execution of a 
with the initial store a yields the store a', then T is true when interpreted as 
a predicate on the stores a and cr', with v as the value of r. Making precise 
the assertion that T is true is not too difficult, since T is simply a formula 
in first-order logic. 

In order to interpret a first-order-logic formula, all one does is give a 
domain (a nonempty set), associate relations on this domain with predicate 
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symbols, associate operations on this domain with function symbols, and 
map variables to elements of the domain [Bar77] . Collectively, the domain, 
the relations, and the operations are called a structure; the mapping of 
variables to elements is called an assignment. In the case of T, we define the 
structure from the stores a and a'; the assignment maps r to v, and maps 
any other free variables of T to their values in the stack. 

Definition 5 (Satisfaction for formulas) Given two stores a and a' , we 
define a structure, as follows: 

• The domain of the structure is {false, irue}U7iU.FU{_L} (so it includes 
booleans, object names, field names, and a special, distinct undefined 
value). 

• false, true, and all field names are interpreted as themselves. 

• a is interpreted as the binary function that maps any d\ and cfo to 
cr(d\)(d2) if this is defined and to _L otherwise. 

• & is interpreted as the binary function that maps any d\ and di to 
v'{d\){d<i) if this is defined and to _L otherwise. 

• alloc is interpreted as the unary predicate that maps any d to true if 
and only if d is in the domain of a. 

• alloc is interpreted as the unary predicate that maps any d to true if 
and only if d is in the domain of a' . 

Given a stack S and a result v, we define an assignment of elements of the 
domain to variables, as follows: 

• r is interpreted as v. 

• Any other variable x is interpreted as S(x) if this is defined and as _L 
otherwise. 

Given a transition relation T, we write (S,a,a',v) |= T if the assignment 
associated with S and v satisfies T in the structure associated with a and a'. 

Two simple lemmas, given next without proof, state some of the prop- 
erties of the notions defined above. 

Lemma 1 (Substitution) If A and B are specifications such that lh A <: 
B, and S is a stack, then AS <: BS. 
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Lemma 2 (Extension) IfE\=S:E and £' h S, t/ien £' |= 5 : £7. 



Theorem 1, given in the main body of this paper, is a special case of 
Theorem 2, which we restate and prove here. 

Theorem 2 Assume that a, S h a ~> u, <r' is provable and that T, \= a. If 
E \\- a : A :: T is provable and T, \= S : E, then (S,cr,a',v) \= T and there 
exists £' suc/i tfca* S' ^ S, S' |= a', and S' |= v : {A, S). 

Proof The proof is a direct induction on the derivation of a, S h a ~> v, a'. 
There is a case for each of the rules of the operational semantics. (Unlike 
in some proofs for Hoare logic [Apt81], the possibility of recursion does not 
lead to the consideration of approximations to recursive procedures.) 

Variables 

S(x) = v 
a, S h x v, a 

Suppose T, \= a, T, \= S : E, and E ¥ x : A :: T. Since E \\- x : A :: T, the 
environment E must contain x: A' for some A' such that lh A' <: A, and 
\\-f 0 l Res(x) T. We obtain: 

• (S,a,a,v) \= T, since \\~f 0 i Res(x) T and (S 1 , a, a, v) \= Res{x) 
(because S(x) = v). 

• S >z S, trivially. 

• X |= u, by hypothesis. 

• S |= v : (A, 5"): Since S |= S : £7, we must have T, \= v : (A',S') for 
some prefix S' of 5, and hence S |=o t> : 5"') for some (A", 5") such 
that A" 5" <: A'S'. Since lh ,4' <: A, the substitution lemma yields 
A'S <: AS. By transitivity, we obtain A"S" <: AS", since A'S' = A'S. 
Therefore, S |= w : (A, S). 

Constants 



cr, 5 h false ~> /a/se, cr cr, S h trwe ~> trwe, cr 

We argue the case for false. Suppose T, \= a, T, \= S : E, and E h /a/se : ^4 :: 
T. Since E lh /a/se : A :: T, we must have A = Bool and \\-f a i Res (false) => T. 
We obtain: 
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• (S, a, a, false) |= T, since \\-j 0 i Res (false) => T and (S, a, a, false) \= 
Res (false). 

• S ^ S, trivially. 

• S |= <7, by hypothesis. 

• S |= /a/se : (Bool, S), by the definitions. 

Conditional 

S(x) = false a, S h ai ~> t>, a' 
ff,Sh i/ x i/ien ao efoe ai ~» u, a' 

S(x) = true a, S h ao ~* v, cr' 
a,S h if x then ao e/se ai ~» u, cr' 

We argue the case for /aZse. Let a be if x then ao else a±. Suppose £ h^ cr, 
T, \= S : E, and E \\- a : A :: T. Since £ lh a : A :: T, we must have 
E 1 lh x : Bool :: Res(x) and there must exist A\, A\, T\, and T{ such that 
E h ai : A\ :: Ti, Aif/aZse/x] = A'-^jalse j x\, T\\false/x] = T^/a/se/x], 
lh A[ <: A, and \\- fol T[ => T. By induction hypothesis, (S,a,a',v) |= Ti 
and there exists £' such that £' ^ S, E' |= cr', and £' |= v : (A^S 1 ). We 
obtain: 

• (S, a, a', v) \= T: Since (S,a,a',v) \= T\ and S(x) = false, we have 
(S,a,a',v) \= T±\false/x]. But T\\false/x] = T{ [fafee/x] , so we have 
(S,a,a',v) |= T{[/a/se/x]. Since S(x) = false, we have (S,a,a',v) \= 
T{. Finally, \\- fol T{ => T yields (5, cr, a', u) |= T. 

• £' ^ S. 

• £' |= a'. 

• £' |= v : (A, S): Since E' |= v : (Ai, S), there exist A' and S" such 
that £' |=o f : (^',5') and A'S' <: AiS. Since S(x) = false and 
^i[/a/se/x] = A[[false/x}, we obtain 7416" = A[S. Since lh ^ <: A, 
the substitution lemma yields A[S <: AS. We obtain A'S" <: AiS = 
A[S <: AS, and hence V \= v: (A, S). 

Let 

cr, S 1 h a ^ v,a' a', S.(x MtiJhKu', cr" 
a, S h let x = a in b v', a" 

Let c be let x = a in b. Suppose T, \= a, T, \= S : E, and E lh c : 
5 :: T. Since £ lh c : 5 :: T, we must have E \\- a : A :: R and 
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E,x:A lh b : :: T' for some i?, B' , and T" such that lh B' <: 5 and 
\\-foi R[a/a, alloc/ alloc, x/r] AT'[a/a, alloc/ alloc] T; in addition, £7 lh B' 
and i£ lh T is a transition relation, so x does not occur free in either B' or T, 
and <7 and a//oc do not occur in T. By induction hypothesis, (S, a, a' , v) |= R 
and there exists £' such that £' ^ S, S' |= a', and S' |= v : (A, 5). 
Since S |= S : E, the extension lemma yields T,' \= S : E. Therefore, 
£' |= S.(x i — ^ f) : (Note that x cannot appear in E because 

E, x: A lh b : B' :: T; hence x is not in the domain of S either.) By induc- 
tion hypothesis, (S.(x i-> v), a', a", v') \= T' and there exists S" such that 
S" >r S', E" |= a", and S" |= «' : (5', ^ «)). We obtain: 

• (S,o,o",rf) |= T: Since (S,<7,o-» \= R and (S.(x ^ u), a', a", v') \= 
T' , the two models associated with (S.(x *— > v),a,a',v') and (5*.(a; 

f ), cj', o~", can be extended to a model for R[&/&, alloc/ alloc, x/r] A 
T'[a/a, alloc/ alloc]. (The interpretation of <r and alloc in this model 
is easily determined from a'.) Since \\-j 0 i R[a/ a, alloc/ alloc, x/r] A 
T'[a/a, alloc/ alloc] T, this is also a model for T. Since a and aZZoc 
do not occur in T and x does not occur free in T, we conclude that 
{S,a,a",v') \= T. 

• S" >z S, by transitivity. 

• S" |= <t". 

• S" |= u' : (5,5): Since S" |= i/ : (B',S.(x ^ v)), there exist B" and 
5" such that E" ho : (-B", 5") and B" S" <: B'{S.{x ^ v)). Since 
x does not occur free in B' , we have B'(S.(x i— > t>)) = Since 
h 2?' <: 23, the substitution lemma yields B'S <: 55. Therefore, 
B"S" <:BS, so E" |=t/: 

Object construction 

S'(xi) = Vi iel - n h i dom{a) heH 

a> = [— > (f. i— > ^ mj ^ {^b^S} ^ 1 - m j) 

a,S\- [U = Xi iel -«, mj = q(yj)bj i el - m ] ~» h,o-' 

Let c be ft = Xi iel - n , mj = q(yj)bj ^ 1 - m ]. Suppose E \= a, T, \= S : E, 
and 2? lh c : A :: T. Since 2? lh c : A :: T, there exists A' of the form 
[U: Ai iel - n , mf^iy^Bj-.-.Tj i el - m ] such that lh A' <: A, E lh a* : Aj :: 
Res(xi) for i G i..n, and E,yfA' lh 6,- : 2?j :: Tj for j £ i..m. In addition, 
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let V be: 

-^alloc{r) A alloc(r) A 
(Vz. z 7^ r {alloc{z) = alloc(z)) ) A 
<j(r, fi) = xi A • ■ ■ A &(r, f n ) = x n A 
(V z,w . z^r =>■ cr(z, = <r(,z, to) ) 

It must be that lh /o / T" T. Let £' be i-» (A', ,9)). We obtain: 

• (5, <r, </, fc) |= T, since (5, <j, </, h) \= V . 

• £' y S, since S and a have the same domain and this domain does 
not include h. 

• T,' \= a': First, £' and <r' have the same domain, namely the domain 
of E and a extended with h. Since S |= <r, we need to check conditions 
only for /i; these conditions are determined by T,'(h) = (A',S). 

— For i 6 l..n, o-'(/i)(fj) is defined, and equals t>j. Since i? Ih x : 
Ai :: Res(xi), it must be that E contains Xf. A\ for some A\ such 
that Ih A\ <: v4j. Since S \= S : E and S(xi) = Vi, we must have 
T, \= Vi : (A^S'A for some prefix S[ of 5, and hence S h^o u i : 

for some (Af, Sf ) such that AfSf <: A'^. Therefore, 
£' |= 0 : (^•',5*f) (because S' b £). Since Ih A' f <: A h the 
substitution lemma yields A^S <: AjS 1 . In addition A^S^ = A^S. 
By transitivity, we obtain A" S" <: AiS. It follows that £' |= Vi : 
(A,S). 

— For j € l..m, a'(v)(m.j) is of the form (s(yj)bj, S), and E, yy. A 1 Ih 
bj : Bj :: Tj. In addition, E is such that T, \= S : E, and hence 
£' |= S : E by the extension lemma. 

• £' |= : (A, 5), since E'(fc) = (A', 5) and A'S <: AS" (because Ih 
A' <: A and by the substitution lemma). 

Field selection 

S(x) = h heH a{h){i)=v 
a, S h x.f v,a 

Suppose T, \= a, T, \= S : E, and I£ Ih x.i : A :: T. Since E Ih x.f : A :: T, 
there exist -B and A' such that B has the form [. . . f: A' . . .], Ih A' <: A, and 
the environment E contains x:B. In addition, lhy 0 ; Res(a(x, f)) =>- T. We 
obtain: 
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• (S, a, a, v) \= T, since v = <j(S(x))(f) so (S,a,a,v) \= Res(a(x,f)). 

• E >z E, trivially. 

• E |= a, trivially. 

• E |= v : (^4,5): Since S |= 5 : £ and £(x) = /i, we must have 
S^/i: (5, -S") for some prefix 5*' of S, and hence E(/i) = (S", 6"') for 
some (B",S") such that B"S" <: 55". Therefore, B" has the form 
[. . .f: A" . . .} with A"S" = A'S'. Moreover, A'S' = A'S since A' is a 
subexpression of B, (B, S') is a specification closure, and S' is a prefix 
of S. Since E |= a, a(h)(f) = v, and E(h) = ([. . . f: A" . . .], S"), we 
have E |= u : (A", 5"), and hence E h= 0 « = (^'", 5"") for some (A'", 5'") 
such that A"'S"' <: A" S". Since lh A' <: A, the substitution lemma 
yields A'S <: AS. By transitivity, we derive A"'S"' <: AS. Therefore, 
X\=v:(A,S). 

Method invocation 

S(x) = h heH a{h){m) = (q{y)b, S') 
a, S'.(y i-> h) h b ~> -y, cr' 

(j, S* h x.m ~» f , o 7 

Suppose E |= cr, E |= S : E, and E lh x.m : A :: T. Since 5 lh x.m : A :: T, 
there exist B, A', T' , and T + such that B has the form [. . . m: s(y)A! ::T' ...], 
h yl'fx/y] <: A, \\~f 0 i T" => T + , and lhj 0 ; T + [x/y] => T, and the environ- 
ment i? contains x: 7?. Since E |= S : E and S(x) = h, we must have 
E |= h : (B,S + ) for some prefix S + of S, and hence E(/i) = (B", S") for 
some (B", S") such that <: BS + . We assume (without loss of gener- 

ality) that y is not in the domain of S" or S. Therefore, B" has the form 
[. . . m: q(y)A" ::T" . . .} with A"S" <: A'S + and T"S" => T'S+. Since E |= 
a, a(h)(m) contains the stack S', and E(/i) = ([. . . m: q{y)A" :: T" . . .], S"), 
we obtain that S" = S' . In addition, there exists E' such that E |= S' : E' 
and E',y:B" lh 6 : A" :: T". Since E(/i) = (5", S") and 5" = 5', 
we obtain that E |= S'.(y i-> /j) : (E',y:B"). (Note that y cannot ap- 
pear in because E',y:B" lh 6 : A" :: T" .) By induction hypothesis, 
(S'.(y ' ^ /i),<7,<t',w) |= T" and there exists E' such that E' ^ E, E' |= cr', 
and E' |= v : (A",S'.(y i— > /i)), and hence there exists (C,U) such that 
S' |=o u : (C, 17) and C£/ <: A"{S'.{y ^ /i)). We obtain: 

• (5,<t,<t / ,«) H T: We have (^'-(y ^ fr),cr,o-» |= T", so (S".(y ' ^ 
fe),<7,<7',u) |= T" since 5" = 6". From T"S" => T'5+ we deduce 
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(S + .(y i ^ h),a,a',v) \= T' . The free variables of T' other than y 
are included in the domain of S + , since (B,S + ) is a specification 
closure and s(y)A' ::T" is a subexpression of B. In addition, S + is a 
prefix of S. Therefore, (S + .(y t— > h),a,a',v) \= T' implies (<5.(?/ i— > 
h),a,a',v) |= T". We obtain i-> h),(7,a',v) |= T+ since lh Jol 

T' =>■ T + , so (5, a, a', v) \= T + [x/y] by substitution and since S(x) = h, 
so (S,a,a',v) (= T since lh /o/ T+fx/y] T. 

• S' ^ S. 

• £' h a'. 

• S' |= -y : (A, S): We already have S' |= 0 v : (C,U). In addition, 
C£7 <: A"(S".(y ' ^ /i)) = A"(S".(y h)) <: A'(S+.(y i-> /i)) = 
A'(S.(y ^ h)) = A'[x/y]S <: AS. (The equality A"(S".(y ^ fc)) = 
A"(S".(y ' — ^ /i)) follows from 5" = 5'. The relation A"(S".(y /i)) <: 
^'(S ,+ .(y i ^ /i)) is obtained from A" S" <: A'S + by substitution. The 
equality A'(S + .(y i-> /j)) = A'(S.(y i-» ft)) holds because q{y)A' ::T' 
is a subexpression of B, (B,S + ) is a specification closure, and S + is 
a prefix of 5. The equality A'{S.{y i— > /i)) = A'fx/yjS 1 holds because 

= ft. The relation A'^/yJS <: AS* follows from lh A'[x/y] <: A 
by the substitution lemma.) 

Field update 

S(x) = h heH <r{h){i) is defined 
S(y) = v a' = a.(h t— > cr(/t).(f i— > v)) 

a, S 1 h x.f := y ~> /i, cr' 

Suppose S |= cr, S |= S : E, and £ lh x.i := y : A :: T. Since £ lh x.i := 
y : A :: T, there exist A' and C such that A' has the form [. . .f: C . . .], 
h A' <: A, and the environment E contains x: A'] and there exists C such 
that lh C <: C and the environment contains y: C . In addition, let T' 
be: 

r = x A a(x, ffc) = y A 

( Vz, tu . = x A to = ffc) => it(z, to) = <r(z, tu) ) A 
(Vz. alloc(z) = alloc(z) ) 

It must be that lh /o/ T' => T. We obtain: 

• (S, a, a', h) |= T since (S, a, a', h) \= T' . 

• S >: S, trivially. 
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E |= a': Since E |= a, we need to check conditions only for a'(h)(f). 
Since T, \= S : E and S'(x) = h, we must have E |= h : {A',S') for 
some prefix S' of S, and hence E(/i) = (A",S") for some (A",S") 
such that A" 5" <: A' 5'. Therefore, A" has the form [. . .f: C" . . .] 
with C"S" = CS". Since E |= 5 : £ and S(y) = v, we must have 
T, \= v : (C, U) for some prefix U of 5, and hence E |=o v : (5', £/') 
for some (£?', !7') such that <: C'C/. Because E(/i) has the form 
([. . .f: C" . . ],S"), we need that E |= u : (C", 5"). We obtain this from 
Sh": and B'U' <: C'U = C'S <: CS = CS' = C" S" . 

(The relation C'S <: CS follows from lh C <: C by the substitution 
lemma. The equality CS = CS' holds because C is a subexpression 
of .A', (A', S') is a specification closure, and S' is a prefix of S.) 

E |= /i : (A,S): We have A" S" <: A'S"; moreover, A'S' = A'S since 
(A', 5") is a specification closure and S' is a prefix of S. Since lh A' <: 
A, the substitution lemma yields A'S <: AS*. By transitivity, we derive 
A"S" <: AS. Therefore, E(/i) = (A", S") yields E |= h : {A, S). 
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